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Abstract 


Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) 
is designed to verify multipoint connectivity. This document 
Specifies the support of P2MP BFD in Transparent Interconnection of 
Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD 
Control packets in TRILL P2MP BFD are transmitted using RBridge 
Channel messages. This document updates RFCs 7175 and 7177. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8564. 
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1. Introduction 


TRILL supports multicast forwarding. 
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Applications based on TRILL 


multicast may need quick detection of multicast failures using P2MP 
[RFC8562]. This document specifies TRILL support of P2MP BFD. 


BFD 


To use P2MP BFD, the head end needs to periodically transmit BFD 


Control packets to all tails using TRILL multicast. 


Channel message is allocated for this purpose. 


A new RBridge 


In order to execute the global protection of distribution used for 
multicast forwarding [TRILL-TREES], the head needs to track the 


active status of tails 


[RFC8563]. If the tail loses connectivity as 


detected by not receiving the new RBridge Channel message from the 
head, the tail should notify the head of the lack of multipoint 
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connectivity with unicast BFD Control packets. These unicast BFD 
Control packets are transmitted using the existing RBridge Channel 
message assigned to BFD Control [RFC7175]. 


This document updates [RFC7177] as specified in Section 3 and updates 
[RFC7175] as specified in Sections 4 and 5. 


2. Acronyms and Terminology 

2.1. Acronyms 
Data Label:  VLAN or Fine-Grained Label [RFC7172]. 
BFD: Bidirectional Forwarding Detection 
P2MP: Point to Multipoint 


TRILL: Transparent Interconnection of Lots of Links or Tunneled 
Routing in the Link Layer 


2.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in 
this document. 


3. Bootstrapping 


The TRILL adjacency mechanism bootstraps the establishment of one- 
hop TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to 
be configured by the network manager. A slight wording update to the 
Second sentence in Section 6 of [RFC7177] is required. 


It currently reads: 


If an RBridge supports BFD [RFC7175], it will have learned whether 
the other RBridge has BFD enabled by whether or not a BFD-Enabled 
TLV [RFC6213] was included in its Hellos. 
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Now it should read: 


If an RBridge supports BFD (see [RFC7175] and [RFC8564]), it will 
have learned whether the other RBridge has BFD enabled by whether 
or not a BFD-Enabled TLV [RFC6213] was included in its Hellos. 


In addition, a normative reference to this document is added to RFC 
7177 as a result of this update. 


4. A New RBridge Channel Message for P2MP BFD 


RBridge Channel protocol number 0x002 is defined for TRILL point-to- 
point BFD Control packets in [RFC7175]. That RFC states that if the 
M bit of the TRILL Header of the RBridge Channel packet containing a 
BFD Control packet is nonzero, the packet is generally dropped. In 
P2MP BFD, the head is required to probe tails using multicast. This 
means the M bit will be set to 1. For this reason, a new RBridge 
Channel message (P2MP BFD Control), whose protocol code point is 
0x007, is specified in this document. An RBridge that supports P2MP 
BFD MUST support the new RBridge Channel message for P2MP BFD. The 
capability to support the RBridge Channel message for P2MP BFD, and 
therefore support performing P2MP BFD, is announced within the 
RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs) 
[RFC7176]. 


As specified in [RFC7178], when the tail receives TRILL Data packets 
sent as BFD RBridge Channel messages, it will absorb the packets 
itself rather than deliver these packets to its attached end 
stations. 


5. Discriminators and Packet Demultiplexing 


The processing in Section 3.2 of [RFC7175] generally applies except 
that the test on the M bit in the TRILL Header is reversed. If the M 
bit is zero, the packet MUST be discarded. If the M bit is one, it 
is processed. 


After the processing per Section 3.2 of [RFC7175], the tail 
demultiplexes incoming BFD packets based on a combination of the 
Source address and My Discriminator as specified in [RFC8562]. In 
addition to this combination, TRILL P2MP BFD requires that the tail 
use the Data Label, which is either the inner VLAN or the Fine- 
Grained Label [RFC7172], for demultiplexing. If the tail needs to 
notify the head about the failure of a multipath, the tail is 
required to send unicast BFD Control packets using the same Data 
Label as used by the head. 
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6. 


Tracking Active Tails 


According to [RFC8562], the head has a session of type MultipointHead 
that is bound to a multipoint path. Multipoint BFD Control packets 
are sent by this session over the multipoint path, and no BFD Control 
packets are received by it. Each tail dynamically creates a 
MultipointTail per a multipoint path. MultipointTail sessions 
receive BFD Control packets from the head over multipoint paths. 


An example use is when a multicast tree root needs to keep track of 
all the receivers as in [TRILL-TREES]; this can be done by 
maintaining a session of type MultipointClient per receiver that is 
of interest, as described in [RFC8563]. See [RFC8563] for detailed 
operations of tracking active tails. 


Security Considerations 


Multipoint BFD provides its own authentication but does not provide 
encryption (see the Security Considerations in [RFC8562]). As 

Specified in this document, the point-to-multipoint BFD payloads are 
encapsulated in RBridge Channel messages that have been extended by 


[RFC7978] to provide security. [RFC7978] provides encryption only 
for point-to-point extended RBridge Channel messages, so its 
encryption facilities are not applicable to this document. However, 
[RFC7978] provides stronger authentication than that currently 
provided in BFD. Thus, there is little reason to use the BFD 
security mechanisms if authentication per [RFC7978] is in use. It is 


expected that a future TRILL document will provide for group keying; 
when that occurs, the use of RBridge Channel security [RFC7978] will 
be able to provide both encryption and authentication. 


For general multipoint BFD security considerations, see [RFC8562]. 


For general RBridge Channel security considerations, see [RFC7178]. 
IANA Considerations 


IANA has allocated the following from the Standards Action [RFC8126] 
range of the "RBridge Channel Protocols" registry, which is part of 
the "Transparent Interconnection of Lots of Links (TRILL) Parameters" 
registry. 


Protocol Number 


P2MP BFD Control  0x007 
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